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Abstract 

This paper proposes some new architectural metrics 
which are appropriate for evaluating the architectural 
attributes of a software system. The main feature of 
our approach is to assess the complexity of a software 
architecture by analyzing various types of architectural 
dependences in the architecture. 

keywords: Architectural description lanaguage, Archi- 
tectural metric, Dependence analysis, Software archi- 
tecture 



1 Introduction 

Software metrics have many applications in software en- 
gineering activities including software analysis, testing, 
debugging, maintenance, and project management, tn 
the past two decades numerous software metrics have 
been proposed for measuring the complexity of software 
j|, p5[ . These metrics can be divided into two categories 
according to the design levels of software^]: code metrics 
which aim at measuring the complexity of a single pro- 
gram module at code design level |}| [5], , and archi- 
tectural metrics which aim at measuring the complexity 
of components and their interconnections in software 
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systems at architectural design level 

Most work on software metrics focused on code met- 
rics which are derived solely from source code of a pro- 
gram, and the study of architectural metrics has re- 
ceived little attention. However, architectural measure- 
ment can be regarded as a desirable addition to code 
metrics because it allows you to capture important as- 
pects of a system's architecture earlier in the system 
life cycle so you can take corrective actions earlier jl6| . 
This may offer greater potential for return on invest- 
ment in order to make large gains in productivity and 
quality since error detection and repair is more costly 
if we can not catch errors in the early stage of system 
design. 



1 There are usually two levels of design for software, architectural 
level design where involves overall association of system capability 
with components, arid-code level design where involves algorithms 
and data structures IX Gl . 



But, why the study of architectural metrics has re- 
ceived little attention in comparison with code metrics 
? One important reason is while the code level for soft- 
ware systems is now well understood, the architectural 
level is currently understood mostly at the level of in- 
tuition, anecdote, and folklore Jl9|. Existing represen- 
tations that a system architect uses to represent the 
architecture of a software system are usually informal 
and ad hoc, and therefore can not capture enough use- 
ful information of the system's architecture. Moreover, 
with such an informal and ad hoc manner, it is diffi- 
cult to develop analysis tools to automatically support 
the evaluation and comparison of existing architectural 
metrics. As a result, in order to make architectural met- 
rics more widely accepted and used in software system 
design, formal representation of system architectures is 
strongly needed. 

Recently, as the size and complexity of software sys- 
tems increases, the design and specification of the over- 
all software architecture of a system is receiving increas- 
ingly attention. The software architecture of a system 
defines its high-level structure, exposing its gross orga- 
nization as a collection of interacting components. A 
well-defined architecture allows an engineer to reason 
about system properties at a high level of abstraction 
[191. Architecture description languages (ADLs) are for- 
mal languages that can be used to represent the archi- 
tecture of a software system. They focus on the high- 
level structure of the overall application rather than the 
implementation details of any specific source module. 
In order to support formal representation and reason- 
ing of software architecture, a number of ADLs such 
as Wright ]l| , Rapide [[| , and UniCon [ 18) have been 
proposed. By using an ADL, a system architect can for- 
mally represent various general attributes of a software 
system's architecture. This provides researchers with 
a promising solution to solve the problems existing in 
recent architectural metrics. First, a sound basis for 
software architecture promises one to define new archi- 
tectural metrics, or refine existing architectural metrics 
in a more formal way in comparing with existing infor- 
mal structure charts based architectural metrics. Sec- 
ond, formal language support for software architecture 
provides a useful platform on which automated support 
tools for architectural metrics can be developed and for- 
mal evaluation and comparison of existing architectural 
metrics can be done. 

In this paper, we propose some new architectural 
metrics for software architecture. Our metrics are ap- 
propriate for evaluating the architectural attributes of a 
software system. The main feature of our approach is to 
assess the complexity of a software architecture by an- 
alyzing various types of architectural dependences in a 



software architecture. To formally define these metrics, 
we present a dependence-based representation named 
Architectural Dependence Graph (ADG) to explicitly 
represent various architectural dependences in a soft- 
ware architecture. 

_ The rest of the paper is organized as follows. Section 
y presents three types of architectural dependences in a 
software architecture and the architectural dependence 
graph. Section |3| defines some dependence-based met- 
rics for software architecture. Section ^ discusses some 
related work. Concluding remarks are given in Section 



2 A Dependence Model for Software Architecture 

When we intend to measure some attributes of an entity, 
we must build some model for the entity such that the 
attributes can be explicitly described in the model. In 
this section, we present a dependence model for software 
architecture to capture attributes concerning about in- 
formation flow in a software architecture. 

2.1 Program Dependences 

Program dependences arc dependence relationships hold- 
ing between program statements (variables) in a pro- 
gram that are implicitly determined by control flow 
and data flow in the program. Usually, there are two 
types of program dependences in a program, that is, 
control dependences representing the control conditions 
on which the execution of a statement or expression 
depends and data dependences representing the flow of 
data between statements or expressions. The task to 
determine a program's dependences is called program 
dependence analysis. 

Program dependence analysis has been primarily stud- 
ied in the context of conventional programming lan- 
guages. In such languages, it is typically performed us- 
ing a program dependence graph IS , ^, |l5| . Program de- 
pendence analysis, though originally proposed for com- 
piler optimization, has also many applications in soft- 
ware engineering activities such as program slicing, un- 
derstanding, debugging, testing, maintenance and com- 
plexity measurement jg, [l5|, As a result, it seems 
reasonable to apply program acpendence analysis tech- 
nique to software architectures to support software ar- 
chitecture development activities |2l], |2^| . 

2.2 Architectural Dependences 

Roughly speaking, architectural dependences are de- 
pendence relationships holding between components (ports) 
in a software architecture, and are implicitly determined 
by information flow in the architecture. Unlike program 
dependences, which are defined as dependence relation- 
ships between statements (variables) in a program, ar- 
chitectural dependences are defined as dependence rela- 
tionships between components (ports) in a software ar- 
chitecture. To perform dependence analysis on software 
architectures, it is important to identify all primary ar- 
chitectural dependence relationships between compo- 
nents (ports) in the architectures. However, such a 
work is quite difficult because comparing with program 
dependence analysis, the dependence relationships be- 
tween components (ports) in a software architecture 
can be more complex and broad. In this section we 
introduce three types of primary architectural depen- 
dences between components (ports) in a software archi- 
tecture. The classification of architectural dependence 



types based on the results of coordination theory jl2| []. 
The types of primary architectural dependences are not 
limited to these three ones, rather, new types of primary 
architectural dependences must be further exploited in 
order to identify all types of primary architectural de- 
pendences in a software architecture. 

Shared Dependences 

Sharing dependences represent dependence relationships 
among consumers who use the same resource or produc- 
ers who produce for the same consumers. For example, 
for two components u and v 7 if u and v refer to the same 
global data, then there exists a shared dependence re- 
lationship between u and v. 

Flow Dependences 

Flow dependences represent dependence relationships 
between producers and consumers of resources. For ex- 
ample, for two components u and v, if u must com- 
plete before control flows into v (prerequisite), or if u 
communicate v by parameters, then there exists a flow 
dependence relationship between u and v. 

Constrained Dependences 

Constrained dependences represent constraints on the 
relative flow of control among a set of activities. For 
example, for two components u and v , u and v can not 
execute at the same time (mutual exclusion) , then there 
exists a constrained dependence relationship between u 
and v. 



2.3 Architectural Dependence Graph 

We present an arc-classified digraph named Architec- 
tural Dependence Graph (ADG) for explicitly represent- 
ing the three types of primary architectural dependences 
in a software architecture. Here we assume that the in- 
terface of each component in a software architecture is 
defined by a set of ports. The ADG of a software archi- 
tecture consists of vertices and arcs to connect these ver- 
tices. There is a component vertex for each component 
in the architecture, and each component vertex consists 
of a set of port vertices each representing a port of the 
component. There is an architectural dependence arc 
between two port vertices of components if there exists 
a shared, flow, or constrained dependence relationship 
between the ports. 

Architectural dependence information can be inferred 
based on formal architectural specifications of a soft- 
ware architecture. For example, based on a Wright 
architectural specification we can infer which ports of a 
component are input ports and which are output ports 
in the specification. Moreover, the direction in which 
the information transfers between ports can also be in- 
ferred based on the formal specification. Such kinds 
of information can be used to construct the architec- 
tural dependence graph for a software architecture to 
formally define dependence-based architectural metrics. 

3 Architectural Metrics 

As we mentioned in Section |[ architectural dependences 
are dependence relationships holding between compo- 
nents in a software architecture that are implicitly de- 
termined by information flow in the architecture. There- 
fore, architectural dependences can be regarded as one 
of intrinsic attributes of a software architecture and it is 
reasonable to regard architectural dependences as one 

2 In fll2| , Malonc and Crowston defines coordination as the process 
of managing dependences among activities. 



of objects for measuring the architectural complexity of 
a software architecture. 

In this section, we define a set of new architectural 
metrics in terms of architectural dependences to assess 
the complexity of a software architecture from various 
different viewpoints. Once the ADG of a software ar- 
chitecture is constructed, the metrics can be computed 
easily based on the graph. The following notations are 
used for defining these metrics: 

\A\: the cardinality of set A. 

R + : the transitive closure of binary relation R. 

a\i] =v (R): the selection of binary relation R such 
that <T[i] =v (R) = {(«l,t>2)|(wl,t>2) G R and vl = 
«}• 

When we constructed the ADG for a software archi- 
tecture, the most general metric can be defined in terms 
of ADG. The following metric is defined for measuring 
the total complexity of a software architecture: 

• Let D t be the set of all dependences arcs in the 
ADG of a software architecture, then the total 
complexity Mj- of the architecture can be mea- 
sured by M T = \D t \. 

Note that the above metric was defined under the 
situation that we treat a component as an unit to con- 
struct the ADG of a software architecture. However, in 
fact, each component in the architecture may generally 
correspond to a single application module which can be 
measured by usual code metrics at code level. So there 
is a need to combine the total complexity at architec- 
tural design level with internal component complexity 
at code design level to obtain an overall complexity met- 
ric. 

• Let Mt be the total complexity and Ml, Mk be 
the individual component complexities. Then the 
global complexity Afg of a software architecture 

can be measured by: Mq = Mt + J2i=i Mi- 

The above metrics only concerned with the direct 
architectural dependences in a software architecture, 
but did not take indirect architectural dependences into 
account. As a result, they only capture the sum of 
some local complexity, rather than the total complexity 
of the architecture. In fact, a component in a soft- 
ware architecture may indirectly depend on other com- 
ponents in the architecture. Therefore, to assess the 
total complexity of a software architecture, we should 
define a metric by taking either direct or indirect ar- 
chitectural dependences into account. This can be ob- 
tained by calculating the transitive closure \Df\ of the 
\D t \, we have: M' T = \Df\. Similarly, if we also con- 
sider the indirect dependences at architectural level and 
each of application modules at code level, we can ob- 
tain more detailed global complexity M' G of the system: 

M' G = M' T + Eli M[. 

In maintenance phases, when we have to modify 
some component in a software architecture, usually, we 
intend to know information about how the modified 
component intersect with other components. This kind 
of information is very useful because it can tell us if 
the modified component is a special point that connects 
with its environment more closely than other compo- 
nents. If so, that means it is difficult to make changes 
to the component due to a large number of potential 



effects on other components. We call such a component 
the "most easily affected component of the architec- 
ture." To capture such attribute, we can define follow- 
ing metrics. 

• Let D t be the set of all dependences arcs in the 
ADG of a software architecture, and (J[i] =v {D t ) be 
the number of ports of components on which a 
port v of a component is directly dependent. The 
complexity Ms of the most easily affected com- 
ponent in the architecture can be measured by 
Ms = max{\a[i} =v (Dt)\ \ v is a vertex of the ADG 

}■ 

Similarly, if we also considered indirect architectural 
dependences in a software architecture, we can obtain 
a more detailed metric: M' s = max{\a^ =v (D^)\ \ v is 
a vertex of the ADG }. 

As we observed, all the architectural metrics defined 
above are absolute metrics. In general, the larger is a 
architectural metric of a software architecture, the more 
complex is the software architecture. Moreover, some 
relative architectural metrics should also by considered 
since they can assess the complexity of a software ar- 
chitecture from some different viewpoints. 

4 Related Work 

Although much work has been studied for code metrics 
at implementation code level, the study of architectural 
metrics has not received as much as attention in com- 
paring with code metrics. Among existing architectural 
metrics, there are two famous architectural metrics that 
have been proposed by Yin and Winchester which is de- 
rived from a system's structured design chart, and by 
Henry and Kafura which is derived from a system's in- 
formation flow. We compare their approaches with ours 
here. 

Yin and Winchester have defined some architectural 
metrics based on analysis of a system's design structure 
chart p2j. They focused on the interface between the 
major levels in a large, hierarchically structure. How- 
ever, the fundamental problem for Yin and Winchester's 
work is that their metrics were defined based on in- 
formal system's design structure charts which can only 
capture the flow of information across level boundaries. 
In contrast, our metrics are defined based on various 
types of architectural dependences in a software archi- 
tecture that can be represented by formal architectural 
specification of a system, and therefore, can measure 
the architectural complexity of the system more well. 

Henry and Kafura proposed some architectural met- 
rics based on information flow of a system. Their met- 
rics are probably the most cited architectural metrics 
that have been developed. The idea behind these met- 
rics is that complexity is measured in terms of infor- 
mation flow, and that more complex modules in a sys- 
tem are those through which large amounts of informa- 
tion flow. Their approach is much more detailed com- 
pared with Yin and Winchester's work because it ob- 
serves all information flow rather than just flow across 
level boundaries. However, there are two fundamental 
problems in information flow metrics. First, although 
Henry and Kafura stated that their approach can be 
completely automated, this is not often the case. Re- 
cent evaluations showed that due to the ambiguous def- 
initions of some of the metrics, it is difficult to give 
an evaluation of the metrics. This makes it difficulty 
to develop automated support tools for the approach 
[ pT[ |2f|. Second, information flow metrics were also 



defined based on some informal structure charts which 
usually poorly capture the attributes of a system's ar- 
chitecture. In contrast, our metrics which are defined in 
terms of various types of architectural dependences in 
a software architecture that can be represented by for- 
mal architectural specification of a system, and there- 
fore can capture more intrinsic and deeper attributes 
of a system s architecture. Moreover, due to the syn- 
thetic nature of some information flow metrics (i.e. the 
fact that they are obtained by combining the values of 
a number of other counts), recent studies showed that 
this may conceal underlying effects and lead to incor- 
rect diagnoses of the status of either the system as a 
whole or of individual components |TT) . Our metrics, 
in contrast, are defined based on primitive counts (of 
dependence arcs in the ADG), rather than synthetics, 
and therefore no such a problem occurred. 

5 Concluding Remarks 



We proposed some new architectural metrics which are 
appropriate for evaluating the architectural attributes 
of a software system. The main feature of our approach 
is to measure the complexity of a software architecture 
by analyzing various types of architectural dependences 
in the architecture. In order to formally define these 
metrics, we presented a dependence- based representa- 
tion named Architectural Dependence Graph (ADG) to 
explicitly represent these architectural dependences in 
the architecture. 

The work presented here is primary, and there is still 
a lot of work that remains to be done. For example, in 
addition to defining metrics based on architectural de- 
pendences, similar to pi which they defined some met- 
rics based on program slices to evaluate functional cohe- 
sion of a program, we can also define metrics to evaluate 
the functional cohesion of a software architecture based 
on architectural slices that can be computed by a new 
slicing technique called architectural slicing |2l| , [23 , 24 



Moreover, we can also define some architectural metrics 
by simply counting the number of elements in a formal 
architectural specification. For example, we can define 
metrics by counting the number of components, connec- 
tions between components, and even the number of lines 
in a formal architectural specification. On the other 
hand, it is important to develop static analysis tools to 
automatically support the collection and evaluation of 
the architectural metrics proposed in this paper. Now 
we are implementing an architectural dependence anal- 
ysis tool for Wright architectural specifications and 
an architectural metric collector based on it. The next 
step for us is to perform some experiments and collect 
data for evaluation. We hope a primary evaluation of 
these metrics will be available soon. 
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